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COMPUTER ARCHITECTURE CONTAINING PROCESSOR AND 

COPROCESSOR 

30990081 EP 

FTFJ,r> OF INVENTION 

The invention relates to computer architectures involving a main processor and a 
coprocessor. 

DHSCRIPTION OF PRIOR ART 

Microprocessor-based computer systems are typically based around a general purpose 
microprocessor as CPU. Such microprocessors are well adapted to handle a wide 
range of computational tasks, but they are inevitably not optimised for all tasks. 
Where tasks are computationally intense (such as media processing) then the CPU 
will frequently not be able to perform acceptably. , 

One of the possible approaches to this problem is to use coprocessors specifically 
adapted to handle individual computationally difficult tasks. Such coprocessors are 
tenned ASICs (Application Specific Integrated Circuits). These are built for specific 
computational tasks, and can thus be optimised for such tasks. They are however 
inflexible both in use and in programming (as they are designed for a specific task 
alone) and are typically slow to produce. Improved solutions can be found by 
construction of flexible hardware which can be programmed with a configuration 
particularly suited to a given computational task, such as FPGAs (Field 
Programmable Gate Arrays). Further flexibility is achieved if such structures are not 
only configurable, but reconfigurable. An example of such a reconfigurable structure 
is the CHESS array, discussed in International Patent Application No. GB98/00262, 
International Patent Application No. GB98/00248, US Patent Application No. 
09/209,542, filed on 11 December 1998, and its European equivalent European Patent 
Application No. 98309600.9. 

Although use of such coprocessors can considerably improve the efficiency of such 
computation, the limitations of the microprocessor acting as CPU can still have a very 




significant effect on overall system performance where such computations are 
required. It would be desirable to improve a processor'-coprocessor system still 
further such that the limitations of the processor have a lesser effect on overall 
performance. 

5 

STnVfMARY OF INVENnQN 

Accordingly, there is provided computer system, comprising: a first processor; a 
second processor for use as a coprocessor to the first processor; a memory; and a 

10 decoupling element; wherein instructions are passed to the second processor from the 
first processor through the decoupling element, such that the . second processor 
consumes instructions derived from the first processor through tiiie decoupling 
element, and wherein the second processor receives data Scorn and writes data to the 
memory, whereby the processing of instmctions by the second processor is decoupled 

1 5 firom the operation of the first processor. 

This arrangement can produce considerable improvements in performance, as the first 
processor, typically a general purpose microprocessor, can switch tasks while 
execution of the instructions is carried out on the second processor, typically a 
20 processor specially adapted to cany out the computation or type of computation 
delegated to it. This is very important when the first processor is the central 
processing unit of a computer device, and thus may be required for a number of other 
tasks. It is a particularly effective arrangement when the second processor is 
configurable or reconfigurable. 

25 

The only task relating to the computation that may be left to the first processor is 
servicing of the decoupling element (so that it can provide instmctions effectively). 
Advantageously, the decoupling element may be set up so that it will require no such 
servicing during performance of the delegated task. 

30 

One possible choice of decoupling elem^t is a coprocessor instraction queue, 
wherein instructions are added to the coprocessor instruction queue by the first 
processor and consumed from the coprocessor instmction queue by the coprocessor. 
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An alternative choice is a state machine, wherein information to provide instructions 
is provided to the state machine by the first processor, and instructions are provided in 
an ordered sequence to the second processor by the state machine. A further 
alternative choice is a third processor, wherein information to provide instructions to 
5 the second processor is provided to the third processor by the first processor, and 
instmctions are provided in an ordered sequence to the second processor by the third 
processor. 

An effective arrangement is for the system to include a coprocessor controller for 
^0 controlling the activity of the second processor and for synchronising the execution of 
the coprocessor with loads from memory. 

The system is particularly effective if it also includes a buffer memory firom which the 
second processor loads data and to which the second processor stores data, wherein 
15 the buffer memory is ad^ted to load data from the memory and store data to the 
memory. This has significant performance benefits for media algorithms in particular 
if the memory is dynamic random access memory, and the buffer memory is adapted 
to load data fixim, or store data to, the buffer memory in bursts. 

20 Decoupling of the first processor from the buffer memory can be achieved by use of a 
second decoupling element, wherein memory instructions relating to movement of 
data between the buffer memory and the memory are passed to the buffer memory 
fiom the first processor through this second decoupling element, such that the buffer 
memory consiunes instructions derived from the first processor through the second 
25 decoupling element. The processing of memory instructions by the buffer memory is 
thus decoupled from the operation of the first processor. 

Where such a buffer memory is used, and as the first processor is decoupled from the 
other system elements, it is desirable for there to be a synchronisation mechanism to 
30 synchronise transfer of data between the buffer memory and the memory with 
execution of instructions by the second processor. Preferably, this is adapted to block 
execution of instructions by the second processor on data which has not yet been 
loaded to the buffer memory fcom the memory, and is adapted to block execution 



memory instractions for storage of data from the buffer memory to the memory where 
relevant instmctions have not yet been executed by the second processor. Greatest 
efficiency is achieved when if execution of instmctions or memory instructions is 
blocked by the synchronisation mechanism, other instructions or memory instmctions 
5 which are not blocked by the synchronisation mechanism may still be carried out. 

In a further aspect, the invention provides a method of operating a computer system, 
comprising: providing code for execution by a first processor; extraction from the 
code of a task to be carried out by a second processor acting as coprocessor to the first 
10 processor; passing information defining the task from the first processor to a 
decoiq)ling element; passing instructions derived from said information from the 
decoupling element to the second processor and executing said instmctions on the 
second processor, wherein the processing of said instmctions by the second processor 
is decoupled from the operation of the first processor. 

15 

RRTRF DESCRIPTION OF FIGURES 

Specific embodiments of the invention will be described further below, by way of 
20 example, with reference to the accompanying drawings, in which: 

Figure 1 shows the basic elements of a system in accordance with a first embodiment 
of the invention; 

25 Figure 2 shows the architecture of a burst buffers stmcture used in the system of 
Figure 1; 

Figure 3 shows further features of the burst buffers structure of Figure 2; 

30 Figure 4 shows the stmcture of a coprocessor controller used in the system of Figure 1 
and its relationship to other system components; 
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Figure 5 shows an example to illustrate a computational model usable on the system 
of Figure 1; 

Figure 6 shows a timeline for computation and I/O operations for the example of 
5 Figure 5; 

Figure 7 shows an annotated graph provided as output from the frontend of a 
toolchain useful to provide code for the system of Figure 1; 

^0 Figure 8 shows a coprocessor internal configuration derived from the specifications in 
Figure 7; 

Figure 9 shows the perfonnance of alternative architectures for a 5x5 image 
convolution using 32 bit pixels; 

15 

Figure 10 shows the performance of the altemative architectures used to produce 
Figure 9 for a 5x5 image convolution using 8 bit pixels; 

Figures llA and IIB show altemative pipeline architectures employing fiulher 
20 embodiments of the present invention; 

Figure 12 shows two auxiliary processors usable as an altemative to the coprocessor 
instroction queue and the burst instruction queue in the architecture of Figure 1; and 

25 Figure 13 shows implementation of a state machine as an altemative to the 
coprocessor instmction queue in the architecture of Figure 1. 



ppsrpTPTfON HP sPFXiiFrr rmbodimbnts 

Figure 1 shows the basic elements of a system in accordance with a first embodiment 
of the invention. EssentiaUy. the system comprises a processor 1 and a coprocessor 2, 
established so that a calculation can be partitioned between the processor 1 and the 



coprocessor 2 for greatest computational efficiency. The processor 1 may be 
essentially any general purpose processor (for example, an i960) and the coprocessor 
2 essentially any coprocessor enable of handling with significantly greater 
effectiveness a part of the calculation. In the specific system described here, 
5 essentially the whole computation is to be handled by the coprocessor 2, rather than 
by the processor 1 - however, the invention is not limited to this specific arrangement. 

In the system specifically described, coprocessor 2 is a form of reconfigurable FPGA, 
as will be discussed further below - however, other forms of coprocessor 2, such as, 
10 for example, ASICS and DSPs, could be employed instead (with corresponding 
modifications to the computational model required). Both the processor 1 and 
coprocessor 2 have access to a DRAM main memory 3, though the processor 1 also 
has access to a cache of faster access memory 4, typically SRAM. EflScient access to 
the DRAM 3 is provided by "burst buffer" memory 5 adapted to communicate with 

15 DRAM for the efficient loading and storing of "bursts" of infomiation - burst buffers 
will be described further below. Instructions to the burst buffers 5 are provided 
through a burst instruction queue 6, and the burst buffers 5 operate under the control 
of a burst buffer controller 7, The architecture of the burst buffers is mirrored, for 
reasons discussed below, in the architecture associated with the coprocessor 2. 

20 Instmctions to the coprocessor 2 are provided in a coprocessor instruction queue 8, 
and the coprocessor operates under the control of a coprocessor controller 9. 
Synchronisation of the operation of the burst buffers and the coprocessor and their 
associated instruction queues is achieved by a specific mechanism, rather than in a 
general maimer by processor 1 itself In this embodiment, the mechanism comprises 

25 the load/execute semaphore 10 and the execute/store semaphore 11, operating in a 
maimer which will be described below (other such synchronisation mechanisms are 
possible, as will also be discussed). 

Description of Elements in Syste m Architecture 

30 

The individual elements of the system will now be discussed in more detail. The 
processor 1 generally controls the computation, but in such a maimer that some (or, in 
the embodiment described, all) of the steps in the computation itself are carried out in 
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the coprocessor 2. The processor 1 provides, through the burst instruction queue 6, 
instructions for particular tasks: configuration of the burst buffer controller 7; and 
transfer of data between the burst buffer memoiy 5 and the main memory 3. 
Furthermore, through the coprocessor instruction queue 8, the processor 1 also 
provides instructions for further tasks: configuration of the coprocessor controller 9; 
and initiation of a computation on coprocessor 2. This computation run on 
coprocessor 2 accesses data through the burst buffer memory 5. 

The use of the coprocessor instruction queue 8 effectively decouples the processor 1 
from the operation of coprocessor 2, and the use of the burst instruction queue 6 
effectively decouples the processor 1 from the burst buffers 5. The specific detail of 
this arrangement is discussed in greater detail below. This decoupling will be 
discussed fiirther below in the context of the computational model for this 
embodiment of the invention. 



The coprocessor 2 performs some or all of the actual computation. A particularly 
suitable coprocessor is the CHESS FPGA structure, described in International Patent 
Application No. GB98/00262, International Patent Application No. GB98/00248, US 
Patent AppUcation No. 09/209,542, filed on 11 December 1998, and its European 
20 equivalent European Patent AppUcation No. 98309600.9, the contents of which 
applications are incorporated by reference herein to the extent peimissible by law. 
This coprocessor is reconfigurable, and comprises a checkerboard array of 4-bit ALUs 
and switching structures, whereby the coprocessor is configurable that an output bom 
one 4-bit ALU can be used to instruct another ALU. The CHESS architecture is 
25 particularly effective for pipelined calculations, and is effectively adapted here to 
interact with input and output data streams. The coprocessor controller 9 (whose 
operation will be discussed further below) receives high-level control instructions 
(instructions for overall control of the coprocessor 2, rather than instructions relating 
to detail of the calculation - e.g. "run for n cycles") from the coprocessor instruction 
queue 8. The CHESS coprocessor 2 runs under the control of the coprocessor 
controller 9 and receives and stores data through interaction with the burst buffers 5. 
The CHESS coprocessor 2 thus acts on ii^ut streams to produce an output stream. 
This can be an efficient process because the operation of the CHESS coprocessor is 



highly predictable. The detailed operation of computation according to this model is 
discussed at a later point. 

The processor 1 has access to a fast access memory cache 4 in SRAM in a 
5 conventional maimer, but the main memory is provided as DRAM 3. Effective access 
to the DRAM is provided by burst buffers 5. Burst buffers have been described in 
European Patent Application No. 97309514.4 and corresponding US Patent 
Application Serial No. 09/3,526, filed on 6 January 1998, which £^plications are 
incorporated by reference herein to the extent permissible by law. The burst buffer 
10 architecture is described briefly herein, but for full details of this architecture the 
reader is referred to these earlier ^plications. 

The burst buffer architecture is usefiil, but not fundamental, to the operation of the 
present invention as described in these embodiments. In the context of the present 
15 invention, the most significant aspect of the burst buffers architecture is that the burst 
buffers 5 operate according to instructions fix)m the processor 1, and that these 
instructions are provided by means of a queue (or alternative, as discussed below). 
This mechanism allows for the possibility of decoupling of the processor 1 from 
operation of the biurst buffers 5 in an appropriate architecture. 

20 

The elements of the version of the burst buffers architecture (variants are available, as 
is discussed in the aforementioned application) used in this embodiment are shown in 
Figures 2 and 3. A cormection 12 for allowing the burst buffers components to 
communicate with the processor 1 is provided. Memory bus 16 provides a cormection 
25 to the main memory 3 (not shown in Figure 2). This memory bus may be shared with 
cache 4, in which case memory datapath arbiter 58 is adapted to allow communication 
to and firom cache 4 also. 

The overall role of burst buffers in this arrangement is to allow computations to be 
30 performed on coprocessor 2 involving transfer of data between this coprocessor 2 and 
main memory 3 in a way that both maximises the efficiency of each system 
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component and at the same time maximises the overall system efficiency. This is 
achieved by a combination of several techniques: 

burst accesses to DRAM, using the burst bufifers 5 as described below; 

simultaneous execution of computation on coprocessor 2 and data transfers 
between main memory 3 and burst buffer memory 5, using a technique called 
"double buffering"*; and 

decoupUng the execution of processor 1 from the execution of coprocessor 2 
and burst buffer memory 5 through use of the instruction queues. 



10 'TJouble buffering" is a technique known in, for example, computer gnphics. In the 
forai used here it involves consuming - reading - data from one part of the burst 
buffer memory 5, while producing - writing - other data into a different region of the 
same memory, with a switching mechanism to allow a region earlier written to now to 
be read from, and vice-versa, 

15 

A particular benefit of burst buffers is effective utilisation of a feature of conventional 
DRAM constraction. A DRAM comprises an array of memory locations in a square 
matrix. To access an element in the array, a row must first be selected (or 'opened'), 
followed by selection of the appropriate column. However, once a row has been 
20 selected, successive accesses to columns in that row may be performed by just 
providing the column address. The concept of opening a row and performing a 
sequence of accesses local to that row is called a "burst".. When data is arranged in a 
regular way, such as in media-intensive computations (typically involving an 
algorithm employing a regular program loop which accesses long arrays without any 
25 data dependent addressing), then effective use of bursts can dramatically increase 
computational speed. Burst buffers are new memory stmctures ad^ted to access data 
from DRAM through efficient use of bursts. 
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A system may contain several burst buffers. Typically, each burst buffer is allocated 
to a respective data stream. Since algorithms have a varying number of data streams, a 
fixed amoimt of SRAM 26 is available to the burst buffers as a burst buffer memory 
area, and this amoimt is divided up according to the number of buffers required. For 
5 example, if the amoimt of fixed SRAM is 2 Kbytes, and if an algorithm has four data 
streams, the memory region might be partitioned into four 512 Byte burst buffers. 

In architectures of this type, a burst comprises the set of addresses defined by: 

10 burst = {B + S X i | B,S,i e ;V a 0 < i < L> 

where B is the base address of the transfer, S is the stride between elements, L is the 
length and ^is the set of natural numbers. Although not explicitly defined in this 
equation, the burst order is defined by / incrementing fixim 0 to Z-l. Thus, a burst may 
15 be defined by the 3 -tuple of: 
{base_address, length, stride) 

In software, a burst may also be defined by the element size. This implies that a burst 
maybe sized in bytes, halfwords or words. The units of stride must take this into 
20 account. A "sized-burst" is defined by a 4-tuple of the form: 
{base_address, length, stride, size) 

A "channel-burst" is a sized-burst where the size is the width of the channel to 
memory. The compiler is responsible for the mapping of software sized-bursts into 
25 channel-biu^. The chaimel-burst may be defined by the 4-tuple: 
(basejaddress, length, stride, width) 

If the channel width is 32 bits (or 4 bytes), the channel-burst is always of the form: 
(base_qddress, length, stride, 4) 

30 

or abbreviated to the 3-tuple {basejaddress, length, stride). 



The control of this memory and the allocation (and freeing) of burst buffers is handled 
at a higher level by a software process. In the present embodiment, "double 
buffering" is used, but other strategies are certainly possible - the decision involves a 
trade-off between storage efficiency and simplicity. The burst buffer memory area 26 
5 loads data from and stores data to the main memory 3 through memory datapath 
arbiter 58, which operates imder control of DMA controller 56, responsive to 
instructions received through the burst instruction queue 6. Data is exchanged 
between the burst buffer memory area 26 and the processor 1 or the coprocessor 2 
through the connection means 12. As shown in Figure 3, the control interface for the 
^[^0 burst buffers system 5 is based around a pair of tables: a Memory Access Table 
(MAT) 65 describing regions of main memory for bursting to and from the burst 
buffer memory, and a Buffer Access Table (BAT) 66 describing regions of burst 
buffer memory. In this embodiment, a homogeneous area of dual-port SRAM is used 
for the bxu^t buffer memory area 26. 

A burst buffers arrangement which did not employ MATs and BATs (such as is also 
described in European Patent Application No. 97309514.4) could be used in 
alternative embodiments of the present invention - the parameters implicitly encoded 
in MATs and BATs (source address, destination address, length, stride) would then 
have to be explicitly specified for every burst transfer issued. The main reason to use 
MATs and BATs, rather than straightforward addresses, lengths and strides, is that 
this significantly reduces the overall code size. In the context of the present 
invention, this is typically useful, rather than critical. 

25 Burst instmctions originating from the processor 1 are provided to the burst buffers 5 
by means of a burst instruction queue 6. Instructions from the burst instmction queue 
6 are processed by a buffer control element 54 to reference slots in the MAT 65 and 
the BAT 66. The buffer controller also receives control inputs from eight burst 
control registers 52, Information contained in these two tables is bound together at 
30 run time to describe a con^)lete main-memory-to-burst-buffer transaction. Outputs 
are provided from the buffer controller 54 to direct memory access (DMA) controller 
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56 and hence to the memory datapath arbiter 58 to effect transactions between the 
main memory 3 and the burst buffers memory area 26. 



The key bxu^t instructions are those used to load data fix)m main memory 3 to the 
5 burst buffer memory area 26, and to store data from the burst buffer memory area 26 
to the main memory 3. These instructions are "loadburst" and "storeburst". The 
loadburst instmction causes a biust of data words to be transferred from a determined 
location in the memory 3 to that one of the burst buffers. There is also a 
corresponding storeburst instruction, which causes a burst of data words to be 
10 transferred from that one of the burst buffers to the memory 3, beginning at a specific 
address in the memory 3. For the architecture of Figure 1, additional synchronisation 
instructions are also required - these are discussed further below. 

The instructions loadburst and storeburst differ from normal load and store 
15 instructions in that they complete in a single cycle, even though the transfer has not 
occurred. In essence, the loadburst and storebiurst instructions tell the memory 
interface 16 to perform the burst, but they do not wait for the burst to complete. 

The fundamental operation is to issue an instmction which indexes to two table 
20 entries, one in each of the memory access and buffer access tables. The index to the 
memory access table retrieves the base address, extent and stride used at the memory 
end of the transfer. The index to the buffer access table retrieves the base address 
within the burst buffer memory region. In the embodiment shown, masking and 
offsets are provided to the index values by a context table (this is discussed further in 
25 European Patent AppUcation No. 97309514.4), although it is possible to use actual 
addresses instead. The direct memory access (DMA) controller 56 is passed the 
parameters from the two tables and uses them to specify the required transfer. 

Table 1 shows a possible instmction set. 
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BB LOADBURST 



BB STOREBURSl 



Parameter Value 

niat_index (integer), 
bat_index (integer), 
block increment (boolean) 



mat_index (integer), 
bat_index (integer), 
block increment (boolean) 



Comment 

Load a burst of data into die burst 
buffer memory from main 
memory, and optionally 
increments the base address in 
main memoiy 

Stoic a burst of data into mam 
memoiy from the burst buffer 
memory. and optionaUy 
increments the base address in 
main memory 




10 



Table 1 : Instruction set for burst buffers 

The storeburst instruction (BB.STOREBURST) indexes paiBmeteis in the MAT and 
BAT which define the characteristics of the requested transfer. If the 
bUxLjncrement bit is set, the memaddr field of the indexed ento' in the MAT is 
automatically updated when the transfer completes (as is discussed below). 

The loadburst instruction (BB.LOADBURST) also indexes parameters in the MAT 
and BAT again which define the characteristics of the required transfer. As before, if 
the block Jncrement bit is set. the memaddr field of the indexed entry in the MAT is 
automatically updated when the transfer completes. 



15 
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The synchronisation instructions needed are provided as Load-Execute Increment and 
eXecute-Store Decrement (BB_LX_INCREMENT and BB_XS_DECREMENT). The 
purpose of BB_LX_INCREMENT is to make sure that the execution of coprocessor 2 
on a particular burst of data happens after the data needed has arrived into the burst 
buffer memory 5 following a loadburst instruction. The purpose of 
BB_XS_DECREMENT is to make sure that the execution of a storeburst instruction 
follows the completion of the calculation (on the coprocessor 2) of the results that are 
to be stored back into main memory 3. 



10 



In this embodiment, the specific mechanism upon which these instructions act is a set 
of two counters that track, respectively: 

the number of regions in burst buffer memory 5 ready to receive a storeburst; 
and 

the number of completed loadburst instractions. 



15 



Requests for data by the coprocessor 2 are performed by decrementing the LX 
counter, whereas the availability of data is signalled by incrementing the XS counter. 
These counters have to satisfy two properties: they must be accessible to only one 
system component at any given time, and they must have the ability to suspend the 
20 process that requests unavailable data. 

The existing concept that matches most closely what is required is the semaphore, as 
described by Dijkstra ("Pijkstra 1968] E. Dijkstra, "Co-operating Sequential 
Processes," in F. Genuys (Editor), Programming Languages, New York: Academic 
25 Press, (1968), pages 43-112.). The term "semaphore" is thus used to describe the 
counters employed in embodiments of the invention - it should be noted however that 
these counters are not identical to the semaphores described by Dijkstra, but broadly 
analogous. 

30 The fundamental principles of the semaphore arc as follows. A semaphore contains 
an integer value. Executing a Wait () instruction on a semqjhore decrements this 
value, whereas executing a Signal () instruction increments it. Executing a 
Wait 0 on a semaphore whose value is abeady 0 stops the software process or 



15 



20 




25 
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hardware component which is trying to execute the Wait () until the value of the 
semaphore is increased. 

In the present embodiment, the BB_XS_DECREMENT instruction would act like a 
Wait 0 on the XS semaphore (1 1 in Figure 1) whereas the BB_LX_INCREMENT 
instruction would act like a Signal () on the LX semaphore (10 in Figure 1). As 
will be described later, the coprocessor controller 9 would, conversely, perform a 
Wait () on the LX semsq^hore 10 and a Signal () on the XS semaphore IL The 
semantics of these instmctions can be the same as described in Dijkstra's paper, 
although the overall arrangement of Signal () and WaitO operations differs 
significantly fi-om that described in the original paper. These instructions would be 
issued in the appropriate sequence (as is discussed further below), in order to make 
sure that the relative temporal ordering of certain events, necessary for the correctness 
of the system, is respected. 

Memory Access Table (MAT) 65 will now be described with reference to Figure 3. 
This is a memory descriptor table holding information relating to main memory 
locations involved in burst transactions. Each entry in the MAT is an indexed slot 
describing a transaction to main memory. In this embodiment, the MAT 65 comprises 
16 entries, though diflFerent implementations are of course possible. Each entry 
comprises three fields: 



1 . Memory address {memaddr) - the start address of the relevant region in 
main memory. Ideally, this location is in physical memory space, as 
virtual address translation may result in a burst request spaiming two 
physical pages, which would cause difficulties for the memory 
controller. 

2. Extent {extent) - the extent of the transfer. This is the length of the 
transfer, multiplied by the stride, and gives the last address transferred 
plus one. The length of the transfer is calculated by the division of the 
extent by the stride, and this is automatically copied to the bufsize field 
of the related BAT 66 (see below) after a transfer has completed. 
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3. Stride (stride) - the interval between successive elements in a transfer. 

memaddr: This is the 32 bit unsigned, word-aligned address of the first element of 
the channel burst. 

5 

extent: The parameter in the extent register is the address offset covering the 

range of the burst transfer. If the transfer requires L elements separated by a stride of 
Sy then the extent is S*L. 

10 stride: The parameter stride is the number of bytes skipped between 

accesses. Values of the transfer stride interval are restricted in the range of 1 to 1024. 
Values greater than 1024 are automatically truncated to 1024. Reads of this register 
return the value used for the burst (i.e. if truncation was necessary, then the truncated 
value is returned). Also, strides must be multiples of the memory bus width, which in 

15 this case is 4 bytes. Automatic tmncation (without rounding) is perfomied to enforce 
this alignment 

An example of values contained by a MAT slot might be: 

20 {Oxlfeelbad, 128, 16} 

which results in a 32 word (32 4 byte words) burst, with each word separated 
by 4 words (4 4 byte words). 

25 The auto-increment indicator bit of a burst instruction also has relevance to the MAT 
65, If this bit is set in the burst instruction, the start address entry is increased to point 
to point to the next memory location should the burst have continued past 32. This 
saves processor overhead in calculating the start address for the next burst in a long 
sequence of memory accesses. 



30 
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The buffer acc^ table (BAT) 66 will now be described with reference to Figure 3. 
This is again a memory descriptor table, in this case holding information relating to 
the burst buffer memoiy area 26, Each entry in the BAT 66 describes a transaction to 
the burst buffer memory area 26. As for the MAT 65, the BAT 66 comprises 16 
5 entries, though can of course be varied as for the MAT 65. Each entry in this case 
comprises two fields: 

1 . Buffer address (jbufaddr) - the start of the buffer in the buffa- area 

2. Buffer size {bufsize) - the size of the buffer area used at the last transfer 

10 The buffer address parameter Jbufaddr is the offset address for the first element of 
the channel-burst in the buffer area. The burst buffer area is physically mapped by 
hardware into a region of the processor's memory space. This means that the 
processor must use absolute addresses when accessing the burst buffer area. 
However, DMA transfers simply use the offset, so it is necessary for hardware to 
15 manage any address resolution required. Illegally aligned values may be 
automatically aligned by truncation. Reads of this register return the value used for 
the biu^t (i.e. if truncation was necessary, then the truncated value is returned). The 
default value is 0. 

The parameter bufsize is the size of the region within the buffer area occupied by 
the most recent burst. This register is automatically set on the completion of a burst 
transfer which targeted its entry. Note that the value stored is the burst length, since a 
value of 0 indicates an imused buffer entry. This register may be written, but this is 
only usefiil after a context switch when buffers are saved and restored. The default 
25 value is again 0. 

Progranuning MAT and BAT entries is performed through the use of BB_SET_MAT 
and BB_SET_BAT instmctions. The entry parameter determines the entry in the 
MAT (or BAT) to which the current instmction refers. 

30 

Fiulher details of the biurst buffer architecture and the mechanisms for its control are 
provided in European Patent Application No. 97309514.4 and the corresponding US 
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Patent Application Serial No. 09/3,526. The details provided above are primarily 
intended to show the architectural elements of the burst buffer system, and to show 
the functional effect that the burst buffer system can accomplish, together with the 
inputs and outputs that it provides. The burst buffer system is optimally adapted for a 
5 particular type of computational model, which is developed here into a computational 
model for the described embodiment of the present invention. This computational 
model is described further below. 

The burst instruction queue 6 has been described above. A significant aspect of the 
10 embodiment is that instructions are similarly provided to the coprocessor through a 
coprocessor instruction queue 8. The coprocessor instruction queue 8 operates in 
connection with the coprocessor controller 9, which determines how the coprocessor 
receives instmctions &om the processor 1 and how it exchanges data with the burst 
buffer system 5. 



Use of the coprocessor instruction queue 8 has the important effect that the processor 
1 itself is decoupled from the calculation itself. During the calculation, processor 
resources are thus available for the execution of other tasks. The only situation which 
could lead to operation of processor 1 being stalled is that one of the instruction 

20 queues 6,8 is full of instructions. This case can arise when processor 1 produces 
instructions for either queue at a rate faster than that at which instructions are 
consimied. Solutions to this problem are available. Effectiveness can be improved by 
requiring the processor 1 to perform a context switch and return to service these two 
queues after a predefined amount of time, or upon receipt of an interrupt triggered by 

25 the fact that the number of slots occupied in either queue has decreased to a 
predefined amoimt. Conversely, if one of the two queues becomes empty because the 
processor 1 cannot keep up with the rate at which instructions are consumed, the 
consumer of those instructions (the coprocessor controller 9 or the burst buffer 
controller 7) will stall until new instructions are produced by the processor 1 . 



Modifications can also be provided to the architecture which ensure that no further 
involvement from the processor 1 is required at all, and these will be discussed in the 
final part of this specification. 
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The basic functions of the coprocessor controller 9 are to fetch data from the burst 
buffer memory 5 to the coprocessor 2 (and vice versa), to control the activity of the 
coprocessor, and to synchronise the execution of the coprocessor 2 with the 
5 appropriate loads from, or stores to, the burst buffer memory 5. To achieve these 
functions, the coprocessor controller may be in essence a relatively simple state 
machine able to generate addresses according to certain rules. 

Figure 4 shows the coprocessor controller 9 in its relationship to the other components 
^[^10 of the architecture, and also shows its constituent elements and its connections with 
other elements in the overall architecture. Its exact function depends on the type of 
inputs and outputs required by the coprocessor 2 and its initialisation requirements (if 
any), and so may vary in detail from that described below. In the case of a CHESS 
coprocessor, these inputs and outputs are input and output data streams exchanged 
15 with the bxirst buffer memory 5. 



Coprocessor controller 9 performs two main tasks: 

control of the communication between the coprocessor 2 and the burst buffer 

memory 5; and 

maintenance of a system state througji the use of a control finite state machine 42, 

The coprocessor 2 accesses data in streams, each of which is given an association with 
one of a number of control registers 41. Addresses for these registers 41 are generated 
m a periodic fashion by control finite state machine 42 with addressing logic 43, 
according to a sequence generated by the finite state machine 42. 

At every tick of a clock within the finite state machine 42, the finite state machine 
gives permission for (at most) one of the registers 41 to have a new address generated 
for it and the address used to allow the register 41 to address the burst buffer memory 
30 5. At the same time, an ^propriate control signal is generated by the finite state 
machine 42 and sent to a multiplexer 44 so that the appropriate address is sent to the 
burst buffer memory 5, together with the correct read/write signal. A specific 
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read/write signal is associated with each register 41, with a value which does not 
change throughout the whole computation. 

After an address obtained for a register 41 has been used to address memory, a 
5 constant quantity is added to its value, generally the same as the width of the 
coimection between the coprocessor 2 and the burst buffer memory 5. That is, if the 
width of this connection is 4 bytes, then the increment made to counter 41 will be 4. 
This is essentially comparable to "stride" in the programming of burst buffers. 

10 The coprocessor controller mechanism described above allows the multiplexing of 
different data streams along a single bus. Each of the data streams can be considered 
to access the single shared bus through its own port. 

For this system to operate such that the integrity of commimication is ensured, it is 
15 necessary that at the other end of the bus the coprocessor 2 is ready to read from and 
write to this bus in a synchronous manner. It is the responsibility of the application 
software (and, specifically, to the part of the application software that configures 
coprocessor 2) to ensure that: 

no two streams try and access the bus at the same time; and that 
20 the execution of coprocessor 2 is synchronous with the data transfer to and from 

burst buffer memory 5. 
This latter requirement ensures that the coprocessor 2 is ready to read the data placed 
by the burst buffers memory 5 on the connection between the two devices, and vice- 
versa. 

25 

Although more than one physical line could usefully be provided between the Chess 
array 2 and the burst buffer memory 5, the general need for multiplexing would still 
remain. Unless the number of physical connections between the coprocessor 2 and 
the burst buffer memory 5 is greater than or equal to the total number of logical I/O 
30 streams for the coprocessor 2, it will always be true fliat two or more logical streams 
have to be multiplexed on the same wire. Technological reasons related to the design 
of fast SRAM (as is advantageously used for the burst buffer memory 5) discourage 
the use of more than one coimection with the coprocessor 2. 

ll?rfeteii:C!t.T0.^;iS.9li \^ 
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The coprocessor controller 9 also acts to control the execution of the CHESS array 
comprising coprocessor 2 so that it will run for a specified number of clock cycles. 
This is achieved by the coimter in the control finite state machine 42 ticking for the 
5 specified number of cycles before "fi-eezing" the CHESS array by "gating" (that is, 
stopping) its internal clock, in a way that does not affect the internal state of the 
pipelines in the coprocessor 2.. This number of ticks is specified using the 
CC_START_EXEC instruction, described below. 

10 Coprocessor controller 9 is programmed by processor 1 through the use of the 
coprocessor instruction queue 8. A possible instruction set for this coprocessor 
controller 9 is shown in Table 2 below. 



Opcode 


Parameter Value 


Comment 


CC_C:URRENT_PORT 


n (integer) 


Port # the next CC_PORT_xxx 
commands will refer to 


CC_PORT_PERIOD 


(integer) 


Period of activity of a port 


CC_PORT_PHASE_START 


start (integer) 


Phase start of the activity of a port 


CX:_PORT_PHASE_END 


end (integer) 


Phase end of the activity of a port 


CC_PORT_TIME_START 


tjrtart (integer) 


Start cycle of the activity of a port 


CC_PORT_TIME_END 


tend (integer) 


End cycle of the activity of a port 


CC_PORT_ADDRESS 


addrstait (integer) 


Initial address for a port 


CC_PORT_ INCREMENT 


addrend (integer) 


Address increment for a port 


CC_PORT_ IS_WRITE 


rw (boolean) 


Read/Write flag 


CC_START_EXEC 


Hcyiics (integer) 


Start/Resume the execution of 
coprocessor 2 for a determined U of 
cycles 


CC„LX_DECREMK^ 


N/A 


Decrement &e value of the LX 
semaphore 


CC_XS_INCREMENT 


N/A 


Increment the value of the XS 
sem^hore 



15 



Table 2: Coprocessor controller instmction set 



-22- 



For the aforementioned instructions, different choices of instruction format could be 
made. One possible format is a 32-bit number, in which 16 bits encode the opcode, 
and 16 bits encode the optional parameter value described above. 

5 

The semantics of individual instmctions are as follows: 

• CC_CURRENT_PORT selects one of the ports as the recipient of all the 
following CC_PORT_xxx instructions, until the next CC_CURRENT_PORT 

• CC_PORT_PERIOD ( ) sets the period of activation of the current port to the 
10 value of the integer parameter 

• CC_PORT_PHASE_START/CC_PORT_PHASE_END (start end) set the 
start/end of the activation phase of the current port to the' value of the integer 
parameter ( start end) 

• CC_PORT_TIME_START/CC_PORT_TIME_END (tstart tend) set the first/last 
15 cycle of activity of the current port 

• CC_PORT_ADDRESS (addrstart) sets the current address of the ciurent port to the 
value of the integer parameter addrstart 

• CC_PORT_INCREMENT (addri„cr) sets the address increment of the current port 
to the value of the integer parameter addrmcr 

20 • CC_PORT_IS_WRITE (rw) sets the data transfer direction for the current port to 
the value of the Boolean parameter rw 

• CC_START_EXEC Ucycies initiates the execution of coprocessor controller 2 for a 
number of clock cycles specified by the associated integer parameter ncycies; 

• CC_LXS_DECREMENT decrements (in a suspensive maimer, as previously 
25 described) the value of the LX semaphore; 

• CC_XSS_INCREMENT increments the value of the XS semaphore, 

A port is defined as active (that is, it has control of the commimication with the burst 
buffer memory 5) if the current value of counter 42, tcur, is such that tstan tcu r<tet,d, and 
30 start (W mod )<end)- This allows the possibility of systems in which, for instance, 
two streams exist, with equal period, say 5, and one has control of the BB memory for 
the first 4 cycles, and the other has control for the remaining cycle. 
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The process of executing an algorithm using this architecture involves first the 
programming of the coprocessor 2, then programming or initialisation of the 
coprocessor controller 9 and the burst buffer controller 7, followed by the actual 
execution of the algorithnL 

5 

For the initialisation of the coprocessor 2, it will generally be most straightforward for 
the configuration to be loaded into the coprocessor itself by means specific to the 
actual embodiment of the device. 



10 For the programming of the coprocessor controller 9, the steps are as follows: 

1. The main coprocessor controller 9 is configured according to the total 
niunber, periods, phases and address increments for every logical 
stream present in the Chess array, as described before. An example of 

15 the programming of the coprocessor controller 9 to perform the desired 

functions is provided below. 

2. The next step in the configuration of coprocessor controller 9 is 
address configuration. Although it is likely that the characteristics 
(period, phase) of every logical stream will remain the same 
throughout an algorithm, the actual addresses accessed by the 
coprocessor controller 9 in the burst buffers memory 5 will vary. It is 
this variability which allows the burst buffers controller 7 to perform 
double-buffering in a straightforward manner within the burst buffers 
architecture. The effect of this double-buffering, as previously stated, 
is to give the coprocessor 2 the impression that it is interacting with 
continuous streams, whereas in fact buffers are being switched 
continuously. 




30 The burst buffers controller 7 also needs to be configured. To do this, the appropriate 
commands have to be sent to the burst instruction queue 6 in order to configure the 
transfers of data to and ftom main memory 3 into the burst buffers memory 5. These 
instructions (BB_SET_MAT and BB_SET_BAT) configure the appropriate entries 
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within the BAT and the MAT, in a manner consistent with the programming of the 
coprocessor controller 9. Li this embodiment, the instructions to program the MAT 
and the BAT entries are issued through the biirst instruction queue 6. An alternative 
possibility would be the use of memory-mapped registers which the processor 1 
5 would write to and read from. As in the present embodiment there is no possibility of 
reading from memory-m^ped registers (as they are not present), processor 1 cannot 
query the state of the burst buffer controller 7 - however, this is not a significant 
limitation. Furthermore, the use of the burst instraction queue 6 for this purpose 
allows the possibility of interleaving instmctions to configure MAT and BAT entries 
10 with the execution of burst transfers, thus maintaining correct temporal semantics 
without the supervision of the processor 1. 



After these steps have been performed, the actual execution of the CHESS array can 
be started. It is necessary in this embodiment only to instruct the CHESS array to run 

15 for a specified number of cycles. This is achieved by writing the exact number of 
cycles as a parameter to a CC_START_EXEC instruction in the coprocessor 
instruction queue 8, so that this data can then be passed to the coprocessor controller 
9. One clock cycle after this value has been transferred into coprocessor controller 9, 
the controller starts transferring values between the burst buffer memory 5 and the 

20 CHESS array of coprocessor 2, and enables the execution of the CHESS array. 




An important step must however be added before instructions relating to the 
computation are placed in the respective instruction queues. This is to ensure the 
necessary synchronisation mechanisms are in place to implement successfully the 

25 synchronisation and double-buffering principles. The basic element in this mechanism 
is that the coprocessor controller 9 will try to decrement the value of the LX 
semaphore and will suspend coprocessor operation until it can do so, according to the 
logic described above. The initial value of this semaphore is 0: the coprocessor 
controller 9 and the coprocessor 2 are hence "frozen" at this stage. Only when the 

30 value of the LX semaphore is incremented by the burst buffers controller 7 after a 
successful loadburst instruction will the coprocessor 2 be able to start (or resume) its 
execution. To achieve this effect, a CC_LX_DECREMENT instruction is inserted in 
the coprocessor instruction queue 8 before the "start coprocessor 2 execution" 

lNSDOCID:<E1 9930465eoe> 



-25- 

(CC_START_EXEC) instruction. As will be shown, a coiresponding "increment the 
LX semaphore" (BB_LX_INCREMENT) instruction will be inserted in the burst 
instruction queue 6 after the corresponding loadburst instruction. 

5 The actual transfer of data between CHESS logical streams and the burst buffer 
memory 5 is carried out in accordance with the progranuning of the coprocessor 
controllCT 9 as previously described. 

The number of ticks for which the coimter 42 has to run depends on how long it takes 
10 to consume one or more input bursts. It is left to the application software to ensure the 
correctness of the system. The programming of the counter 42 must be such that, once 
a buffer has been consumed, the execution of coprocessor 2 will stop. The next 
instruction in the coprocessor instmction queue 8 must be a synchronisation 
instruction (that is, a CC_LX_DECREMENT), in order to ensure that the next burst of 
15 data has arrived into the burst buffers memory 5. Following this instmction (and, 
possibly, a waiting period until the data required is available), the initial address of 
this new burst of data is assigned to the data stream (with a CC_PORT_ADDRESS 
instmction), and execution is resumed via a CC_START_EXEC instruction. The 
procedure is similar for output streams (with the important difference that there will 
20 be no waiting period equivalent to that required for data to arrive from main memory 
3 into burst buffers memory 5). 



Computational Model 

An illustration of the overall computation model will now be described, with 
reference to Figure 5. The illustration indicates how an algorithm can be receded for 
use in this architecture, using as an example a simple vector addition, which can be 
coded in C for a conventional microprocessor as: 

int a 11024], b [1024 J, c[1024]; 
f or {i=0 ; i<1024 ; i++) 
a[i]=b[i]+c[il ; 
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A piece of C code to run processor 1 which achieves on the architecture of Figure 1 
the same functionality as the original vector addition loop nest is as follows: 



10 



15 



20 



25 



30 



35 



40 



45 



0 : 


int a. ri024l bri024l rflo^Al - 




1 : 


int eo not eo Ic • 




2 : 


/ *Poirt 0 SDeC f XCat i on • "OOT^t it i pir'-r-»mi»Tit- "v-Po-*- o «* A 


perxoa. 


3 : 


pxidse BL.cix.ii,f pxidse ena, suairc uime^ end time, r/w*/ 


*± • 


^-J-U^o XKiiMra V u, ^, 4, J, U,.l, 0, 3 *BIjEN*MAXK+3 , 0 ) ; 




^ • 


/ Jtrux. X o^c^x J. X ion / 




V • 


*-±y_& AKi!iMi*M 4, 4, J, 1, 0, 3 *BLEN*MAXK+3 , 0 ) ; 




/ : 


/ *Por't 2 specif i.catjL on*/ 




o • 
o : 


CIQ_STREAM { 2, 4, 4, 3, 2, 3, 0, 3 *BLEN*MAXK+3 , 1 ) ; 






B1Q_SET__^MAU lU, ScDlO}, BLEN*4, 4); , 




10 


: BIQ_SET_MAT(1, &C [0] , BLEN*4 , 4) ; 




11 


: BIQ_SET_MAT(2, &a[0], BLEN*4 , 4) ; 




12 


: BIQ_SET_BAT(0, 0x0000, BLEN*4) ; BIQ_SET_BAT(1, 0x0100, 


BIiEN*4) ; 


13 


: BIQ_SET_BAT(2, 0x0200, BIiEN*4) ; BIQ_SET_BAT (3 , 0x0300, 


BLEN*4) ; 


14 


: BIQ_SET_BAT{4, 0x0400, BLEN*4) ; BIQ_SET_BAT (5 , 0x0500, 


BIiEK*4) ; 


15 


: for( k = 0; k < MAXK; k++ ) 


16 


= { 




17 


: /*Even or odd iteration? - For double buffering*/ 




16 


: eo = k&Oxl; 




19 


: CIQ_IiXD (2) ; 




20 


: CIQ_SA(0, (BIiEN*4*eo) ) ; 




21 


: CIQ_SA(1, ( (2*BIjEN*4) +BLEN*4*eo) ) ; 




22 


: CIQ_SAC2, ( (4 *BIjEN*4 } +BLEN*4*eo) ) ; 


















AoX \X.} , 




^ o 


/^nn fai-iiF'F*/ 

/ OO DwUXJ. 




27 


: /*Load A*/ 




2 8 






29 


: /*Load B*/ 




30 


: BIQ_FLB (2,2+eo) ; 




31 


BIQ liXI (2) ; 




32 


: if ( k 1 ) 




33 


{ 




34 


not_eo = (eo==0)?l:0; 




35 


BIQ_XSD(1); 




36 


BIQ FSB(4,4+not eo) ; 




37 


} 




38 


= } 




39 


eo « MAXK & 0x1; 




40 


not_eo = (eo-*0) ?1:0,• 




41: 


BIQ_XSD(1) ; 




42 : 


BIQ_FSB (4 , 4+not_eo) ; 





In this axrangement, three ports are used in coprocessor controller 9: one for each 
input vector (b and c) and one for the output vector (a). The statements at lines 4, 6 
50 and 8 are code macros to initialise these three ports. These, when expanded, result in 
the following commands (this is with reference to line 4 - the other expanded macros 
are directly analogous): 
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CC_CURRENT_PORT ( 0 ) ; 
CC_P0RT_INCREMENT(4) ; 
CC_TRANS FER_S I ZE ( 4 ) ; 
CC_PORT_PERIOD ( 3 ) ; 
5 CC_PORT_PHASE_START ( 0 ) ; 
CC_P0RT_PHASE_END(1) ; 
CC_PORT_START_TIME ( 0 ) ; 
CC_PORT_END_TIME(3*BLEN*MAXK+3) ; 
CC_PORT-,IS_WRITE(0) ; 

This code has the effect that port 0 will read 4 bytes of data every 3"* tick of counter 
42, and precisely at ticks 0, 3, 6 ... 3*BLEN*MAXK+3, and will increment the 
address it reads from by 4 bytes each time. BLEN*MAXK is the length of the two 
vectors to sum (in this case, 1024), and BLEN is the length of a single burst of data 
1 5 fix)m DRAM (say, 64 bytes). With these values, MAXK will be set to 1 024/64=1 6. 

Lines 9 to 14 establish MATs and BATs for the burst buffers transfers, tying entries in 
these tables to addresses in main memory 3 and burst buffers memory 5. The 
command BIQ_SET_MAT(0, &b[0], BLEN*4, 4. TRUE) is a code macro that is 
expanded into BB_SET_MAT(0, &b[0], BLEN*4, 4) and ties entry 0 in the MAT to 
address &b[0], sets the burst length to be BLEN*4 bytes (that is, BLEN integers, if an 
integer is 32 bits) and the stride to 4. The two lines that follow are similar and relate to 
c and a The line BI(^SET_BAT(0. 0x0000, BLEN*4) is expanded to 
BB_SET_BAT(0, 0x0000, BLEN*4) and ties entry 0 of the BAT to address 0x0000 
in the burst buffers memory 5. The two lines that follow are again similar. 

Up to this point, no computation has takoi place; however, coprocessor controUw 9 
and burst buffers controUer 7 have been set up. The loop nest at lines 15 to 38 is 
where the actual computation takes place. This loop is repeated MAXK times, and 
30 each iteration operates on BLEN elements, giying a total of MAXK*BLEN elements 
processed. The loop starts with a set of instructions ClQjaix sent to the coprocessor 
instruction queue 8 to control the activity of the coprocessor 2 and coprocessor 
controller 9, followed by a set of instructions sent to the burst instruction queue 6 




10 
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whose purpose is to control the burst buffers controller 7 and the burst buffers 
memory 5. The relative order of these two sets is in principle unimportant, because 
the synchronisation between the different system elements is guaranteed expUcitly by 
the semaphores. It would even be possible to have two distinct loops running after 
each other (provided that the two instruction queues were deep enough), or to have 
two distinct threads of control. 

The CIQ_xxx lines are code macros that simpUfy the writing of the source code. Their 
meaning is the following: 

CIQ_LXD(N) inserts N CC„LXS_DECREMENT instructions in the 
coprocessor instruction queue 8; 

CIQ_SA(port, address) inserts a CC_QJRRENT_PORT(port) and a 
CC_PORT_ADDRESS(address) instmction in the coprocessor instruction 
queue 8; 

15 CIQ_ST(cycleno) inserts a CC_EXECTJTE_START{cycleno) instruction in 

order to let the coprocessor 2 execute for cycleno ticks of counter 42; and 
CIQ_XSI(N) inserts N CC_XSS,INCREMENT mstructions in. the 
coprocessor instruction queue 8. 

20 The net effect of the code shown above is to: 

synchronise with a corresponding loadburst on the LXS semaphore; 

start the computation on coprocessor 2 for 3*BLEN ticks of counter 42; and 

synchronise with a corresponding storeburst on the XSS semaphore. 

25 The BIQ_xxx Unes are again code macros that simplify the writing of the source code. 
Their meaning is as follows: 

BIQ_FLB(mate,bate) inserts a BB_LOADBURST(mate, bate, TRUE) 
instruction into the burst instruction queue 6; 

BIQ_LXI(N) inserts N BB_LX_INCREMENT instructions in the burst 
30 instruction queue 6; 

BIQ_FSB(mate,bate) inserts a BB_STOREBURST(mate, bate, TRUE) 
instruction into the burst instruction queue 6; and 



ho 
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BIQ_XSD(N) inserts N BB_XS_DECRE^4ENT instructions in the burst 
instniction queue 6. 

The net effect of the code shown above is to load two bursts from main DRAM 
memoiy 3 into burst buffers memory 5, and then to increase the value of the LX 
semaphore 10 so that the coprocessor 2 can start its execution as described above. In 
aU iterations but the first one, the results of the computation of coprocessor 2 are then 
stored back into main memory 3 using a storeburst instruction. It is not stricUy 
necessary to wait for the second iteration to store the result of the computation 
executed in the first iteration, but this enhances the parallelism between the 
coprocessor 2 and the burst buffers memory 5. 

The use of the two variables eo and not_eo is a mechanism used here to allow the 
double-buffering effect described previously. 

Lines 39 to 42 perform the last burst transfer to main memory 3 from burst buffers 
memory 5, compensating for the absence of a storeburst instruction in the first 
iteration of the loop body. 

20 The resulting timeline is as shown in Figure 6. Loadbursts 601 are the first activity 
(as until these are completed the coprocessor 2 is stalled by the load/execute 
semaphore), and when these are completed the coprocessor 2 can begin to execute 
602. The next instruction in the burst instruction queue 6 is another loadburst 601, 
which is carried out as soon as the first two loads have finished.. Then, the next 

25 instruction in the burst instruction queue 6 is a storeburst 603, which has to wait until 
the XS semaphore 11 signals that the first computation on coprocessor 2 has 
completed. This process continues throughout the loop. 

Although the example indicated above is for a very simple algorithm, it illustrates the 
30 basic principles required in calculations that are more complex. The person skilled in 
the ait could use the approach, principles and techniques indicated above for 
programming the architecture of Figure 1 to adapt more complex algoritiims for 
execution by this architecture. 
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Tool chain for computation 

5 The principles of the computation model can be exploited in straightforward fashion 
by hand coding - that is, manually writing C code to run on the CPU adapted in 
conventional manner to schedule the appropriate operation of the system components 
(to place instructions in the appropriate queues, and to set the system components into 
operation as described), and to provide an appropriate configuration for the 

10 coprocessor in accordance with the standard synthesis tools for configuring that 
coprocessor. For a configurable or FPGA-based processor like CHESS, this tool will 
generally be a hardware description language. An appropriate hardware description 
language to use for CHESS is JHDL, described in, for example, "JHDL - An HDL for 
Reconfigurable Systems" by Peter Bellows and Brad Hutchings, Proceedings of the 

15 IEEE Symposium on Field-Programmable Custom Computing Machines y April 1998. 

A preferred alternative is for a specific toolchain to be used for this computational 
architecture. The elements of such a toolchain and its practical operation are 
described briefly below, 

20 

The toolchain has the function of converting conventional sequential code to code 
adapted specifically for effective operation, and interoperation, of the system 
coniponents. The exemplary toolchain receives as input C code, and provides as 
output the following: 
25 a CHESS coprocessor configuration for execution of the computation; 

biust buffer schedule for moving data between the system memory and the 

burst buffer memory; and 

a coprocessor controller configuration for moving data between the CHESS 
coprocessor and the burst buffer memory. 



30 



The toolchain itself has two components. The first is a fix)ntend, which takes C code 
as its input and provides armotated dependence graphs as its output. The second 
component is a backend, which takes the dependence graphs generated by the 
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frontend, and produces from these the CHESS configuration, the burst buffers 
schedule, and the coprocessor controller configuration. 



10 



15 



20 



25 



The main task of the fiontend is to generate a graph which aptly describes the 
computation as it is to happen in coprocessor 2. One of the main steps performed is 
value-based dependence analysis, as described in W. Pugh and D. Wonnacott, "An 
Exact Method for Analysis of Value-based Array Data Dependences", University of 
Maryland, Institute for Advanced Computer Studies - D^t. of Computer Science, 
University of Maryland, December 1993 . The output generated is a description of 
the dataflow to be implemented in the CHESS array and a representation of all the 
addresses that need to be loaded in as inputs (via loadburst instructions) or stored to 
as outputs (via storeburst instructions), and of the order in which data has to be 
retrieved from or stored to the main memory 3. This is the basis upon which an 
efficient schedule for the burst buffers controller 7 wiU be derived. 

If we assume, as an example, the C code for a 4-tap FTR filter: 

int i, j , src [] , kernel [] , dst [] ; 
for{ i = 0; i < 1000; i++ ) 
for( j = 0; j < 4; j++ ) 

dst[il = dst til + srcl4+i-jl*kemel[j] ; 

as the input to the frontend, the output, provided as a text file, will have the following 
form: 



loop:0<=i<999 #loop nest description 
loop:0<=j<:4 

16:str/0/0/20/ #store instruction 
LOD: 

30 #Array:d [1/0/0] at line 11 

20:ldc/16/0/0/ #load constant 
22:str/0/0/26/ #store instruction, which 
LOD: 4 <= j #writes its outputs to main 
#Array:d (1/0/0] at line 13 ttmemory if 4<:=j 

35 26:add/22/27/3l/ #addition 
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27 :lod/26/0/0/ #load instruction, taking its inputs 
Dep(l6): [0] [0] / Range: j <= 0 #froni instruction 16 if .j<=o 
Dep(22): [0] [1] / Range: 1 <= j #froin instruction 22 otherwise 
LID: 

#Array;dIl/0/0] at line 13 
31:mul/26/32/37/ #nniltiplication 
32 :lod/31/0/0/ #load instruction 
Dep(32): [1] [1] / Range: 1 <= i it i <= j 

LID: i <= 0 I I j <. 0 i& 1 <= i #which takes its inputs from main 
#Array:src[l/-l/0] at line 13 #memory if i <= 0 | | j <= o &6 i <= i 
37 :lod/31/0/0/ 

Dep(37):. {1] [0] / Range: 1 <= i #load instruction 
LID: i <= 0 Staking its inputs from main memory if 
#Array : kernel lO/l/O] at line 13 #i<=0 

This text file is a representation of an annotated graph. The graph itself is shovm in 
Figure 7. The graph clearly shows the dependencies found by the fiontend algorithm. 
Edges 81 are marked with the condition under which a dependence exists, and the 
dependence distance where applicable. The description provided contains all the 
information necessary to generate a hardware component with the required 
functionality. 

The backend of the compUation toolchain has certain basic fimctions. One is to 
schedule and retime the extended dependence graph obtained bom the fiontaid. This 
25 is necessary to obtain a fiilly functional CHESS configuration. Scheduling involves 
determining a point in time for each of the nodes 82 in the extended dependence graph 
to be activated, and retiming involves, for example, the insertion of delays to ensure 
that edges propagate values at the appropriate moment Scheduling can be performed 
using shified-linear scheduling, a technique widely used in hardware synthesis. 
Retiming is a common and quite straightforward task in hardware synthesis, and 
merely involves adding an appropriate number of registers to the circuit so that 
different paths in the circuit meet at the appropriate point in time. At this point, jve 
have a con^lete description of the functionality of the coprocessor 2 (here, a CHESS 
coprocessor). This description is shown in Figure 8. This description can then be 
passed on to the appropriate tools to generate the sequence of signals (commonly 
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referred to as "bitstream") necessary to program the CHESS coprocessor with this 
functionality. 

Another function required of the backend is generation of the burst buffer and 
5 coprocessor controller schedule. Once the CHESS configuration has been obtained, it 
is apparent when it needs to be fed with values fiom main memory and when values 
can be stored back to main memory, and the burst buffer schedule can be established. 
Accordingly, a step is provided which involves splitting up the address space of all the 
data that needs to be loaded into or stored from the burst buffers memory S into fixed 
f 10 bursts of data that the burst buffers controller 7 is able to act upon. 

For instance, in the FIR example just presented, the input array (src[]) is split into 
several bursts of appropriate sizes, such ttiat all the address range needed for the 
algorithm is covered. This toolchain uses bursts of length Bien (where Bien is a power 
15 of 2, and is specified as an execution parameter to the toolchain) to cover as much of 
the input address space as possible. When no more can be achieved with this burst 
length, the toolchain uses bursts of decreasing lengths: Bicn/2, Bieii/4, Bien/8, 2, I 
until every input address needed for the algorithm belongs to one and only one burst. 

20 For each one of these biusts, the earliest point in the iteration space in which any of 
the data loaded is needed is computed. In other words, to each input burst there is 
associated one point in the iteration space for which it is guaranteed that no earlier 
iterations need any of the data loaded by the burst. It is easy to detect when the 
execution of the coprocessor 2 would reach that point in the iteration space. There are 

25 thus created: 



a loadburst instmction for the relevant addresses, in order to move data into 
burst buffer memory 5; and 



30 



a corresponding synchronisation point ( a CC_LX_DECREMENT / 
BB_LX_INCREMENT pair) to guarantee that the execution of coprocessor 2 
is synchronised with the relevant loadburst instruction. 
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To achieve an efficient overlap of computation and communication, the loadburst 
instruction has to be issued in advance, m order to hide the latency associated with the 
transfer of data over the bus. 

5 All the output address space that has to be covered by the algorithm is partitioned into 
output bursts, according to a similar logic. Again, the output space is partitioned into 
bursts of variable length. 

The toolchain creates: 
10 a storeburst instmction for the relevant addresses; 

a corresponding synchronization point (BB_XS_DECREMENT / 
CC_XS_INCREMENT pair) 

At this point, we possess information relevant to: 
1^ relative ordering of loadburst and storeburst instructions, and their 

parameters of execution (addresses, etc.) 

their position relative to the computation to be performed on coprocessor 2. 
This information is then used to generate appropriate C code to organise the overall 
computation, as in the FIR example described above. 

20 

The actual code generation phase (that is, the emission of the C code to run on 
processor 1) can be accomplished using the code generation routines contained m the 
Omega Library of the University of Maryland, available at 
http://www.cs.umd.edu/projects/omega/ , followed by a customised script that 
25 translates the generic output of these routines into the form described above. 



Experimental Results - Image Convnlnrinn 



An image convolution algorithm is described by the following loop nest: 



30 for (i=0 ; i<IMAGE_HEIGHT; i++) 
for ( j =0 ; j < IMAGE_WIDTH ; j ++) 
for (k=:0 ; k<KERNEL_HEIGHT; k++) 
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f or (1=0 ; 1<KBRNEL_WIDTH; 1++) 

Dest[i,j] += Source ( -k, -H*C[k,l] ; 



Replication has been used to enhance the source image by keriiel_hbight-1 pixels in 
5 the vertical direction and kernel_width-1 pixels in the horizontal direction in order 
to simplify boundary conditions. Two kemels are used in evaluating system 
perfomiance: a 3x3 kernel and a 5x5 kernel, both performing median filtering. 

Figures 9 and 10 illustrate the performance of the architecture according to an 
10 embodiment of the invention (indicated as BBC) as against a conventional processor 
using burst buffers (indicated as BB) and a conventional processor-and-cache 
combination (indicated as Cache), Two versions of the algorithm were implemented, 
one with 32-bit pixels and one with 8-bit pixels. The same experimental 
measurements were taken for different image sizes, ranging from 8x8 to 128x128, and 
15 for different burst lengths. 

As can be seen from the Figures, the BBC implementation showed a great 
performance advantage over the BB and the Cache implementations. The algorithm is 
relatively complex, and the overall performance of the system in both BB and Cache 

20 implementations is heavily compute-bound - the CPU simply carmot keep up because 
of the high complexity of the algorithm. Using embodiments of the invention, in 
which the computation is vastly more effective as it is carried out on the CHESS array 
(with its inherent parallelism), the performance is if anything lO-bound - even though 
lO is also efficient through effective use of burst buffers. Multimedia instructions 

25 (such as MIPS MDMX) could improve the performance of the CPU in the BB or the 
Cache implementations, as they can allow for some parallel execution of arithmetic 
instmctions. Nonetheless, the performance enhancement resulting is unlikely to reach 
the performance levels obtained using a dedicated coprocessor in this arrangement. 

30 Modifications and Variations 



The function of decoupling the processor 1 from the coprocessor 2 and the burst 
buffer memory 5 can be achieved by means other than the instruction queues 6,8. An 
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effective alternative is to replace the two queues with two small processors (one for 
each queue) fully dedicated to issuing instructions to the burst buffers memory 5 and 
the coprocessor 2, as described in Figure 12. The burst instruction queue is replaced 
(with reference to the Figure 1 embodiment) by a burst command processor 106, and 
5 the coprocessor instruction queue is replaced by a coprocessor command processor 
108. Since this would be the only task carried out by these two components, there 
would be no need for them to be decoupled fiom the coprocessor 2 and the burst 
buffers 7 respectively. Each of the command processors 106, 108 could operate by 
issuing a command to the coprocessor or burst buffers (as appropriate), and then do 
10 nothing until that command has completed its execution, then issue another command, 
and so on. This would complicate the design, but would free the main processor 1 
from its remaining trivial task of issuing instructions into the queues. The only work 
to be carried out by processor 1 would then be the initial setting up of these two 
processors, which would be done just before the beginning of the con^jutation. 
15 During the computation, the processor 1 would thus be completely decoupled from 
the execution of the coprocessor 2 and the burst buffers memory 5. 

Two conventional, but smaller, microprocessors (or, alternatively, only one processor 
running two independent threads of control) could be used, each one of them running 

20 the relevant part of the appropriate code (loop nest). Alternatively, two general state 
machines could be synthesised whose external behaviour would reflect the execution 
of the relevant part of the code (that is, they would provide the same sequence of 
instructions). The hardware complexity and cost of such state machines would be 
significantly smaller than that of the equivalent dedicated processors. Such state 

25 machines would be programmed by the main processor 1 in a way similar to that 
described above. The main difference would be that the repetition of events would be 
encoded as well: this is necessary for processor 1 to be able to encode the behaviour 
of one algorithm in a few (if complex) instructions. In order to obtain the repetition of 
an event x times, the processor 1 would not have to insert x instructions in a queue, 

30 but would have to encode this repetition parameter in the instruction definition. 

As indicated above, a particularly effective mechanism is for finite state machines 
(FSMs) to be used instead of queues to decouple the execution of the main processor 
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1 from the execution of coprocessor 2 and the burst buffers controller 7. This 
mechanism will now be discussed in further detail. 

In the architectiire illustrated in Figure 1, instructions to drive the execution of 
5 different I/O streams can be mixed with instructions for execution of coprocessor 2. 
This is possible because the mutual relationships between system components is 
known at compile time, and therefore instructions to the different system conq^onents 
can be interleaved in the source code in the correct order. 

^jjjj^lO Two state machines can be built to issue these instructions for execution in much the 
same way. One such state machine would control the behaviour of the coprocessor 2, 
issuing CC_xxx_xxx instructions as required, and the other would control the 
behaviotu* of burst buffers controller 7, issuing BB_xxx_xxx instructions as required. 

Such state machines could be implemented in a number of different ways. One 
alternative is indicated in Figure 13. With reference to the vector addition example 
presented above, this state machine ISO (for the coprocessor 2, though the equivalent 
machine for the burst buffers controller 7 is directly analogous) implements a 
sequence of instructions built from the pattern: 
CC_LX_DECREMENT, 
CC_LX_DECREMENT, 
CC_START_EXEC, 
CC_XS_INCREMENT. 

25 The main state machine ISO is effectively broken up into simpler state machines ISl, 
1S2, 1S3, each of which controls the execution of one kind of instruction. A period 
and a phase (note, this has no relationship to periods and phases which can be 
associated with I/O streams conmiunicating between the coprocessor 2 and the burst 
buffers controller 7) is assigned to each of the simpler state machines. The hardware 
30 of state machine ISO will typically contain an array of such simpler state machines in 
a number sufficient to satisfy the requirements of intended applications. 
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An event counter 154 is defined. The role of the event counter 154 is to allow 
instructions (in this case, for coprocessor 2) to be sent out in sequence. Each time the 
event counter 154 is incremented, if there exists a value M such that 
M*Periodi+Phasei=value of Event Counter, the state machine i (i.e. one of the simpler 
state machines 151, 152, 153) is chosen for execution through comparison logic 155, 
and its instruction is executed. It is the responsibility of the application software to 
ensure that no two distmct state machines can satisfy this equation. When the 
execution of that instmction is completed, the event counter 154 is incremented again. 
This sequence of events can be summarised as: 



10 



1 : Increment event counter EC-H- 

2: Choose state machine i for execution if there exists an M such that 

M*Periodri-Phasei=EC 
3: If such a state machine i has been found, execute the instmction described by 
15 state machine i (this could include a suspension operation) 

4: Go back to 1 

A few extra parameters relevant to the execution of an instmction (addresses to read 
fiiom/write to, length of execution for a CC__START_EXEC, etc.) will have to be 
20 encoded in the state machine 150. It should also be noted that more than one state 
machine can issue a given instruction, typically with different parameters. 

This system works particularly well to generate periodic behaviour. However, if an 
event has to happen only once, it can readily be encoded in a simple state machine 
25 with infinite period and finite phase, the only consequence being that this simple state 
machine will be used only the once. 



This approach can itself be varied. For example, to add flexibility to the mechanism, 
a possible option is to add *start time' and *end time' parameters to the simple state 
30 machines, in order to limit the execution of one or more simple state machines to a 
predetermined *time window'. 
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The progranuning of these state machines would happen during the initialisation of 
the system, for example through the use of memory-mapped registers assigned by the 
processor 1. An altemative would be the loading of all the parameters necessary to 
program these state machines from a predefined region of main memory 3, perhaps 
5 through the use of a dedicated channel and a Direct Memory Access (DMA) 
mechanism. 

The other alternative mechanism suggested, of using two dedicated microprocessors, 
would require no significant modification to the progranuning model for the 
10 architecture of Figure 1 : the same techniques used to program main processor 1 could 
be used, with an additional step of splitting commands intended for the coprocessor 2 
fiom those intended for burst buffers controUer 7. Although feasible, this 
arrangement may be disadvantageous with respect to the state machine approach. It 
would be necessary for these processors to be provided with access to main memory 3 
15 or other DRAM, adding to the complexity of the system. The cost and complexity of 
the system would also be increased by adding (and underutilising, in that they are only 
present to perform very simple computations) two microprocessors in this way. 

Various developments beyond the architecture of Figure 1 and its alternatives can also 
20 be made without departing firom the essential principles of the invention. Three such 
areas of development will be described below: pipelines, data dependent 
conditionals/unknown execution times, and non-affine accesses to memory. 

Pipeline architectures have value where appUcations require more than one 
transformation to be carried out on their input data streams: for instance, a 
convolution may be followed immediately by a correlation. In order to accommodate 
this kind of arrangement, changes to both the architecture and tiie computational 
model wiU be required. Architectiirally, successive buffered CHESS arrays could be 
provided, or a larger partitioned CHESS array, or a CHESS array reconfigured 
between computational stages. Figures 11 A and IIB show different pipeline 
architectures effective to handle such appUcations and involving plural CHESS arrays. 
Figure 11 A shows an arrangement with a staggered CHESS/burst buffer pipeline 
instructed bom a processor 143 and exchanging data with a main memory 144, where 
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a CHESS array 141 receives data from a first set of burst buffers 142 and passes it to a 
second set of burst buffers 145, this second set of burst buffers 145 interacting with a 
further CHESS airay 146 (potentially this pipeline could be continued with further 
sets of CHESS arrays and burst buffers). Synchronisation becomes more complex, 
5 and involves communication between adjacent CHESS arrays and between adjacent 
sets of burst buffers, but the same general principles can be followed to allow eflBcient 
use of burst buffers, and eflBcient synchronisation between CHESS arrays: 
semaphores could be used to guarantee the correctness of the computation carried out 
by successive stages of the pipeline. 

10 

Figure 1 IB shows a different type of computational pipeline, with an SRAM cache 
155 between two CHESS arrays 151, 156, with loads provided to a first set of burst 
buffers 152 and stores provided by a second set of burst buffere 157. The role of the 
processor 153 and of the main memory 154 is essentially unchanged fiom other 
15 embodiments. Synchronisation may be less diflBcult in this arrangement, although the 
arrangement may also exploit parallelism less effectively. 

One constraint on efficient use of the coprocessor in an architecture as described 
above is that the execution time of the coprocessor implementation should be known 

20 (to allow efficient scheduling). This is achievable for many media-processing loops. 
However, if execution times are unknown at compile time, then the scheduling 
requirements in the toolchain need to be relaxed, and appropriate allowances need to 
be made in the synchronisation and communication protocols between the processor, 
the coprocessor and the burst buffers. The coprocessor controUer also will need 

25 specific configuration for this circumstance. 



Another extension is to allow non-afiOne references to burst buffers memory. In the 
burst buffers model used above, aU access is of the type AI+F, where A is a constant 
matrix, I is the iteration vector and F is a constant vector. Use of this limited access 
30 model allows the coprocessor controUer and the pix)cessor to know in advance what 
data will be needed at any given moment in time, aUowing efficient creation of logical 
streams. The significance of this to the architecture as a whole is such that it is 
unclear how non-afGne access could be provided in a completely arbitrary way (the 



-41 - 

synchronisation mechanisms would appear to break down), but it would be possible to 
use non-affine array accesses to reference lookup tables. This could be done by 
loading lookup tables into burst buffers, and then allow the coprocessor to generate a 
burst buffer address relative to the start of the lookup table for subsequent access. It 
5 would be necessary to ensure that such addresses could be generated sufficiently far in 
advance to the time that they will be used (possibly this could be achieved by a 
refinement to the synchronisation mechanism) and to modify the logical stream 
mechanism to support this type of recursive reference. 

10 Many variations and extensions to the architecture of Figure 1 can thus be carried out 
without deviating finom the invention as claimed. 
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CLAIMS 

30990081 EP 

1 . A computer system^ comprising: 
a first processor; 

a second processor for use as a coprocessor to the first processor, 

a memory; and 

a decoiq)ling element; 



wherein instructions are passed to the second processor firom the first 
processor through the decoupling element, such that the second processor 
15 consumes instructions derived fipom the first processor through the decoupling 

element, and wherein the second processor receives data fiom and writes data 
to the memory, whereby the processing of instructions by the second processor 
is decoupled fiom the operation of the first processor. 

20 2. A computer system as claimed in claim 1, wherein the decoupling element is a 
coprocessor instmction queue, wherein instructions are added to the 
coprocessor instruction queue by the first processor and consumed Grom the 
coprocessor instruction queue by the coprocessor. 

25 3. A computer system as claimed in claim 1, wherein the decoupling elraient is a 
state machine, wherein information to provide instmctions to the second 
processor is provided to the state machine by the first processor, and 
instructions are provided in an ordered sequence to the second processor by 
the state machine. 



4. A computer system as claimed in claim 1, wherein the decoupling element is a 
third processor, wherein information to provide instructions to the second 
processor is provided to the third processor by the first processor, and 
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instructions are provided in an ordered sequence to the second processor by 
the third processor. 

5. A computer system as claimed in any preceding claim, further comprising a 
coprocessor controller for controlling the activity of the second processor and 
for synchronising the execution of the coprocessor with loads fix>m memory. 

6- A computer system as claimed in any preceding claim, wherein the second 
processor is configurable. 

7. A computer system as claimed in claim 6, wherein the second processor is 
adapted to be configured in accordance with a configuration downloaded fi^om 
the memory. 



15 8. A computer system as claimed in any preceding claim, wherein the first 
processor is able to switch tasks during execution of instructions by the second 
processor. 



9, A computer system as claimed in any preceding claim, fiirther comprising a 
20 buffer memory &om which the second processor loads data and to which the 

second processor stores data, wherein the buffer memory is ad£q>ted to load 
data fi*om the memory and store data to the memory. 



10. A computer system as claimed in claim 9, wherein the memory is dynamic 
25 random access memory, and the buffer memory is adapted to load data from, 

or store data to, the buffer memory in bursts. 



11. A computer system as claimed in claim 9 or claim 10, further comprising a 
second decoupling element, wherein memory instructions relating to 
30 movement of data between the buffer memoiy and the memoiy are passed to 

the buffer memory Scorn the first processor through the second decoupling 
element, such that the buffer memory consumes instructions derived Gcom the 
first processor through the second decoupling element, whereby the processing 
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of memory instructions by the buffer memory is decoupled from the operation 
of the first processor. 



12. 

5 



13. 

•><> 



15 14. 



20 



25 

16. 



A computer system as claimed in claim 11, wherein the second decoupling 
element is a buffer memory instruction queue, wherein memory instractions 
are added to the buffer memory instruction queue by the first processor and 
consumed from the buffer memory instruction queue by the buffer memory. 

A computer system as claimed in claim 11, wherein the second decoupling 
element is a state machine, wherein infomiation to provide memory 
instractions to the buffer memory is provided to the state machine by the first 
processor, and memory instructions are provided in an ordered sequence to the 
buffer memory by the state machine. 

A computer system as claimed in claim 11, wherein the second decoupling 
element is a fourth processor, wherein information to provide memory 
instructions to the buffer memory is provided to the fourth processor by the 
fu^ processor, and memory instractions are provided in an ordered sequence 
to the buffer memory by the fourth processor. 

A computer system as claimed in any of claims 9 to 14, fiirther comprising a 
synchronisation mechanism to synchronise transfer of data between the buffer 
memory and the memory with execution of instractions by the second 
processor. 

A computer system as claimed in claim 15, wherein the synchronisation 
mechanism is adapted to block execution of instractions by the second 
processor on data which has not yet been loaded to the buffer memory from 
the memory, and is adapted to block execution memory instractions for 
storage of data fix>m the buffer memory to the memory where relevant 
instractions have not yet been executed by the second processor. 
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17. A computer system as claimed in claim 16, adapted such that when execution 
of instmctions or memory instructions is blocked by the synchronisation 
mechanism, other instructions or memory instructions which are not blocked 
by the synchronisation mechanism may be carried out. 

5 

18. A computer system as claimed in any previous claim, wherein the first 
processor is the central processing unit of a computer device. 



19. A method of operating a computer system, comprising: 

10 

providing code for execution by a first processor; 



extraction fi-om the code of a task to be carried out by a second 
processor acting as coprocessor to the first processor; 

15 

passing information defining the task fix>m the first processor to a 
decoupling element; 

passing instructions derived fix>m said information fix>m the decoupling 
20 element to the second processor and executing said instmctions on the 

second processor, wherein the processing of said instructions by the 
second processor is decoupled fiom the operation of the first processor. 
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ABSTRACT 

30980081 EP 

Computer Architecture Containing Proces sor And Coprocessor 

5 A computer system comprises a first processor 1 and a second processor 2 for use as a 
coprocessor to the first processor 1. The system has a main memory 3. The system 
also has a decoupling element 8 such that instructions are passed to the second 
processor 2 from the first processor 1 through the decoupling element 8. This has the 
efifects that the second processor 2 consumes instmctions derived from the first 
10 processor 1 through the decoupling element 8, and that the second processor 2 
receives data from and writes data to the memory 3. The processing of instructions by 
the second processor 2 can thus be decoupled &om the operation of the first processor 
1. 

15 This is particularly effective for processing of a computationally intensive task (such 
as a media computation) on an architecture with a general purpose first processor 1, 
using a second processor 2 adapted for the computationally intensive task. This can 
effectively be combined with use of a buffer memory 5 adapted to exchange data 
particularly rapidly with the memory 3 in response to memory instructions, together 

20 with a fiuther decoupling element 6 to decouple the buffer memory 5 fix)m the first 
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